If you want to use suntar 2.0 only on floppy disks, as you did with previous versions, you need no more informations. But otherwise, you're entering a world which is not well known to normal Macintosh users, and sometimes even to experienced users. Suntar 2.0 may do things at a lower level than Norton or other utilities: e.g. they can show you any sector in a disk partition, but suntar can show you sectors in the partition map, or in a non-Mac partition, or in a disk without a Mac-like partition map.
Obviously you may follow the method which is typical on the Mac: simply launch the application and experiment. But if you are afraid of doing that, or you have problems, I'll try to explain how the Macintosh handles devices.
If you want to use suntar 2 with a tape unit, you should read anyway the last sections of this file.
Note that an option ("supported ops" 14) is described in the section about tapes but is meaningful to all people using the command "Drive list".
Devices, drivers and drive numbers
A device, e.g. a hard disk, is not so simple as you may think: at least, there is a number of components and each one changes the rules, that is what must be done to access the device.
The read/write head on the disk gets and requires analog signals, that is electric signals whose value change with time. The "controller" takes these signals and transforms them into digital signals, i.e. a sequence of binary numbers.
The controller for the floppy disk is connected directly to the Macintosh, but the applications running on it should never access it direcly, for two reasons: one, Apple may change it in future Macs and you want that your old applications will run on them too; two, chip manufacturers adore making controllers very difficult to use: if they may save a cent in the manufactoring cost but in doing so they make the rules so innatural that a programmer must experiment for a few days before beginning to understand what that chip really does and its manual confusely tried to explain, well, you may bet that's the design which goes into production, and in order to avoid every programmer the burden of handling that chip, Apple has introduced a set of rules to write a "device driver".
A "device driver" is similar to an application since it runs on your Macintosh, but it's dissimilar from an application since you never see it: only applications see it and they send to it commands like "read the 1000th sector", which the device driver translates into a series of operations on the controller.
Launch suntar and select the "Drive list" command (in Expert mode): you'll get something like this (obviously without the extra comments):
driver nr. -2 is .Sony (ROM) don't care, it's duplicated here only for
compatibility with the pre-Mac Plus "HD20"
driver nr. -4 is .Sound (ROM) sends sounds to the speaker
driver nr. -5 is .Sony (ROM) the floppy disk
driver nr. -6 is .AIn (ROM) serial port
driver nr. -7 is .AOut (ROM)
driver nr. -8 is .BIn (ROM) serial port
driver nr. -9 is .BOut (ROM)
driver nr. -33 is .SCSI00 (RAM nonrelocatable) the internal hard disk
driver nr. -49 is .Display_Video_Apple_V8 (ROM) even that requires a driver !
Some drivers know that the device which is accessed through them may contain a "file system" hence they tell to the System software that a number of "volumes" may be mounted through a "drive number" (don't confuse drives and drivers !): the Drive list command tells also about that (you need not be in Expert mode):
drive 1 driver -5 (.Sony) Standard floppy disk drive
SuperDrive (GCR 800k-MFM 720/1440k) not present
drive 8 driver -33 (.SCSI00) ID=0 fixed disk mounted as "HD40"; blocks=81984
Only drives are guaranteed to accept regular read/write commands, hence only device drivers connected to drive numbers may be opened by suntar. Beware: a driver may be connected to many drives and some drivers, just to be sure to have enough drive numbers, create a lot of drives, that does not hurt the user since before a drive is mounted you don't see it, but that means that you may see drives which don't correspond to any physical device and are marked "not present".
When you use suntar to open a drive number, suntar talks to the driver which then talks to the hardware: e.g. when you open drive 1 .Sony, suntar will be able to read and write on the internal floppy disk drive. If you insert a disk when suntar is running but has nothing open it will intercept the event and will check if it's a Macintosh or MS-DOS disk: if it isn't suntar opens the device driver for that drive.
SCSI hard disks and their drivers
The inclusion of a SCSI port on the Mac Plus introduced a new level of complexity: the SCSI protocol is complex enough to require a small computer which converts the commands specified by the SCSI standard to operations on the controller: that small computer is inside the box containing the disk, and that's why an hard disk for the Mac costs more than a hard disk for a PC clone. The job which usually was performed by the device driver on the Mac is performed by the computer inside the disk box, but a device driver is still needed since the Finder and the applications can speak only the language of the device drivers, not the language of SCSI: such languages are very similar but parameters occupy a different number of bits and are placed in different positions. So, the ".SCSI00" device driver performs the translation for my internal disk "HD40".
That seems simple, but Apple made things more complex deciding that the device driver for a SCSI device must reside on the disk itself, in a special partition (hard disks are always partitioned, even when you see only one partition). E.g. here is what suntar tells about my hard disk:
Partition map test
Disk in Apple format block size=512 number of blocks=82080
partition name="Macintosh" type="Apple_Driver" start=64 size=32 (the device driver)
partition name="MacOS" type="Apple_HFS" start=96 size=81984 (the "HD40" volume)
When the Macintosh boots it performs a few "SCSI READ" commands, if it finds a driver then it loads it, and then the system software does not perform any more any SCSI commands, it only sends driver commands to the driver. Probably Apple was afraid of manufacturers which do not follow the SCSI standard: if the SCSI READ command works, at least for small sector numbers, and the manufacturer provides a formatting utility which writes to the disk a device driver which knows how to do anything else, then that disk may be used on any Mac without having to install any additional software. That's how a driver may compress or encrypt the disk without any incompatibility problem.
So, a SCSI device may belong to one of these categories:
a) regular disks: the manufacturer may give you some utilities, but if the drive comes formatted for the Mac it may be immediately connected to your Mac and it's mounted on the desktop when you boot
b) non-disks, e.g. printers, scanners, tape units: obviously they'll never be mounted hence the boot procedure will not find a device driver on them. The device is sold with a floppy disk containing some software (maybe a device driver, but often an application) which allows you to use the device: without that software, the device exists only for utilities which talk directly to the SCSI bus, such as SCSIProbe and suntar
c) removable disks: according to Apple rules they should be recognized and mounted only if a disk is present when the Mac boots. That's foolish, and that's why the manufacturer gives you a floppy disk with some software (a device driver !) to be put in the System folder so that the drive list will be correctly updated anyway. However, if the disk is present the device driver in the disk is loaded first, and remains there when you swap disks: a removable disk may happen to be handled by different device drivers according to what you've done with that drive, and that's exactly what Apple wanted to avoid when it decided to put the driver on the disk itself. See the documentation of SCSIProbe for more informations
d) floppy-disk compatibles (e.g. floptical drives, or 1440k drives for Mac Pluses and old SEs): compatibility forbids to put a partition map and a device driver on a standard floppy disk, otherwise it would not be considered a Mac disk when inserted in the internal floppy drive (the .Sony driver does not handle partitions). At least in one case that was solved without requiring software in the system folder, by storing the partition map and the device driver in nonvolatile silicon memory in the SCSI controller and letting it cheat: the SCSI command "READ sector 0" return sector 0 of this fixed partition map telling that there is a device driver partition and a Mac HFS partition: only requesting a sector in the HFS partition one gets data from the real disk.
Suntar may access SCSI devices directly, by sending standard SCSI comands on the SCSI bus, or it may access them through their device driver, if one exists. However, in most cases the two methods are NOT equivalent, since the device driver lets you access a partition, not the entire disk.
When using suntar to access non-Mac disks in the "normal" cases a) and c), you must open the device as a SCSI ID, since the device driver (if one is loaded) does not see a partition map and issues only error messages or maybe shows a subset of the real disk as the "Mac partition" (some drivers don't read the partition map but use fixed sector numbers as start and end of the Mac partition); in case d) you should use the device driver, since the "Mac partition" is the real disk. For non-disk devices suntar can't open the device driver, if any exists, hence the SCSI ID is the only possible door: obviously printers and scanners don't recognize "read sector" commands: suntar allows you to try, but that's because a rigid refusal would prevent you from using units that do behave like hard disks but do not declare to be hard disks, e.g. Apple's 40 Megabyte tape unit (now out of production and totally obsolete).
When a device driver or a SCSI device is opened, suntar creates a "Device" menu containing some commands which may be useful: Eject, Mount… there are three different versions of this menu for device drivers, non-tape SCSI devices, tape devices.
Beware: through the device menu you can directly send some SCSI commands (e.g. stop motor): it's a level of power that I believe no other utility can give you. That's powerful, but it's also dangerous. Some time ago I stopped the motor of my hard disk, then quitted suntar. Well, the Finder can't restart the motor and suntar was inaccessible on the stopped disk: powering off the Macintosh was the only way to exit from that situation, so now suntar forbids a number of operations on the startup disk, but it may still send very destructive commands: writing to the partition map, for example, and neither Norton nor MacTools can then recover anything on that disk: they talk to the disk through the device driver, which works only when there is a valid partition map. That's why you must pass two levels of alert dialogs (and a "allow write commands" command) before being able to write.
Tape units
Since the "t" of tar means tape, a tar program which supports SCSI devices should support tape units: however, that part of suntar is somewhat immature and probably only it version 2.0.4 it should be considered no more "beta" software, mainly because
1) tape units can't be found everywhere, and sometimes there are problems with cabling (e.g. Sun units do not use the standard SCSI 50-pin connectors). Hence we've personally tested suntar 2.0 on only three tape units, and only one of these tests lasted enough to try all the solutions and not only identify the problems.
2) the SCSI standard is not perfectly clear, and even where the standard is clear and does not specifies that details are "vendor specific", some vendors do not follow it faithfully, so the situation is somewhat chaotic
3) the SCSI committee defined a standard set of commands which should allow one to control devices from different manufacturers without writing specific code (i.e. device driver) for each one: however, this feature has had a very low priority: most commands and features are optional, and there is no way to know which ones are supported and which ones are not: for a while almost all manufacturers included a list of supported commands (but not of supported options) in the "vendor specific" informations returned by the SCSI "inquiry" command, but older devices didn't do that, and unfortunately SCSI-2 did not make that list official, hence manufacturers are now deleting that information in new versions of SCSI controllers that once had them.
Suntar 2.0.2 was tested on a Exabyte EXB-8200 unit, and suntar 2.0.0beta4 on a ARCHIVE VIPER (a quarter-inch unit). Tests were usually successful, and since suntar 2.0.1 could not work with the Exabyte, we hope that the problems reported by users having other units (WangDAT, HP 35480A, HP C1533A) are now solved. Only for the ARCHIVE Python we've got a report about 2.0.2 having solved all the previous problems.
Anyway, if suntar fails you might try the other freeware tar program for the Macintosh, Craig Ruff's tar, which in version 4.0 added support for tapes. And a user of suntar wrote us that there is a commercial tar for the Macintosh, here is what he could know about it:
it's part of "QuTape" (695 $)
Novastor Corp.
30961 Agoura Road, Suite 109
Westlake Village, CA 91361
Phone: +1 (818) 707-9900
Guide to configuration for tapes
Sorry, suntar can't self-configure for your tape unit. The SCSI standard is rather poor in this regard, and we have not the know-how to build a table of configurations for all kinds of units. So, you must configure it, and unfortunately this means understanding some very technical matters. Obviously, you may prefer to try all the configurations, without trying to understand what each means, but since most options are independent you can't really try all the combinations, they are too many…
The first thing to learn is that the tape options for suntar are under "Rarely used options", available only if "Expert mode" is checked. Some options were collected together under two names, "supported operations" and "unsupported operations", which must contain a list of numbers separated by commas: if an operation is in neither list, then suntar uses the default value (that's why there are two lists). E.g. the correct configuration for the Exabyte is:
unsupported: 2,3,11 (but maybe it was a problem of timeouts, I did not try
again after correcting that)
supported: 0,1,7,9,10,13 (since it's the default none is required; you may
add 4 if you want)
This is the configuration for an Archive Scorpion 60 Mbyte unit:
unsupported: 1 (maybe also 3: the beta-tester did not try that)
supported: 0,2,7,10,11,13
block strategy=don't care (it's a fixed blocks unit)
do MODE SELECT=don't care (it's a fixed blocks unit)
And we were told that an Archive Python worked well with the default settings.
A tape is a rather flexible device, since in most cases it allows data to be written in "blocks" of any size. On a UNIX machine this feature is hidden by the device driver (in UNIX all devices are a simple stream of bytes) but running on the Mac suntar must know about blocks and block sizes. If the block size known to the application is wrong the tape unit may refuse to return any byte, or at least issue an error. Furthermore, the SCSI manager in the Mac ROM was written with hard disks in mind, and it may report an error to the application even when the tape unit correctly fulfilled the request.
So, in order to use suntar with a "variable-size blocks" tape unit you must configure the way it uses to handle block sizes: these methods are 4, and you may be obliged to try 3 of them looking for the correct one.
a) fixed blocks
It's automatically selected for a "fixed block" tape unit, that is when minimum block size=maximum block size, regardless of the value of "tape block strategy". So, if the minimum and maximum size are identical (e.g. 512 bytes for the VIPER) you need not read the rest of the discussion about block sizes.
The following options may modify the behaviour in this mode:
supported/unsupported bit 4: if it's supported, suntar makes a single request for a number of adjacent blocks, that's faster but in some cases suntar might fail to count correctly the bytes in the last transfer and hence incorrectly identify the position of the end-of-archive (default: unsupported).
b) really variable blocks
It's obtained by setting "tape block strategy" to any string starting with 'v' or 'y' (e.g. variable).
When reading, suntar tries to fill the buffer, accepting any block length the tape unit has available, with the only condition that it's an integer multiple of 512 bytes.
When writing, it's identical to software fixed blocks.
Unfortunately, there are a number of potential problems and this method, conceptually the simplest for handling variable blocks, might fail to work. On my LC it has always worked, but it exploits an undocumented feature of the Mac ROM which I was told is not supported on the Quadras. The Quadras support a totally new SCSI Manager which has a documented feature which should solve the problem, but it does not run on the LC so we haven't tried it yet.
In this mode the following options are meaningful:
do a MODE SELECT: when opening the device do a MODE SELECT with a block size of 0 (the conventional value meaning "variable sized blocks"). Some units (e.g. Exabyte) don't work in variable mode without this.
supported/unsupported bit 5: if unsupported, do a MODE SENSE before every READ and ask that many bytes (it's an unusual way to do things, but I've written the instructions to do that and it does not harm to let the option there)
c) "software" fixed blocks (the name is not standard, don't expect to see it elsewhere)
It's obtained by setting "tape block strategy" to any string starting with 's' (really, anything not starting with 'v', 'y' or 'f')
When reading, suntar uses the "variable blocks" variant of the SCSI READ command, but expects each block to be 512*"blocking factor" bytes, it's an error to see different block sizes. That's a reasonable strategy since most programs (including all versions of tar) always write blocks of fixed size even when the tape unit is potentially variable-blocks.
When writing, suntar always creates blocks of size 512*"blocking factor".
The blocking factor is another "rarely used option": in theory it should be equal to the -b option passed to tar under UNIX (or 20 if the -b option is not used) but in some cases
the UNIX device driver might ignore that and use its own value. If the value is incorrect, suntar should print the correct value, so you should assign it, close the device (some options are activated only at the next "Open device"), reopen it, rewind and retry.
Options:
do a MODE SELECT: when opening the device do a MODE SELECT with a block size of 0 (on the Exabyte it's required, otherwise it does not work in this mode)
supported/unsupported bit 5: when opening the device do a MODE SENSE and if the returned value is not 0 use that value instead of 512*"blocking factor".
d) "firmware" fixed blocks (the name is not standard, don't expect to find it elsewhere)
It's obtained by setting "tape block strategy" to any string starting with 'f'. This mode exploits a feature of the SCSI command set for tape units, so the "variable blocks" units may accept "fixed blocks" requests.
Options:
do a MODE SELECT: when opening the device do a MODE SELECT with a block size of 512*"blocking factor", in order to oblige the tape unit to work in the fixed-blocks mode
supported/unsupported bit 5: if unsupported, the block size is obtained by a MODE SENSE rather than being 512*"blocking factor", but if its response is 0 then software fixed blocks are used. Obiously, using both this option and the previous one is not very meaningful (the MODE SELECT uses the value from the MODE SENSE, so nothing changes)
supported/unsupported bit 4: see its description for fixed blocks
Some units work in several modes: the Exabyte when reset is in "firmware fixed" mode with a blocking factor of 2, but it may work in "really variable" (do a MODE SELECT=yes), "software fixed" (again do A MODE SELECT=yes, and pay attention to the blocking factor also when reading, not only when writing) and "firmware fixed" (do a MODE SELECT either no or yes if the blocking factor is 2, otherwise yes).
Some suggestions:
Many commands are not performed when the tape is moving or is not in the correct position. So, before launching a tar extraction observe the unit (the Exabyte has a green LED) or use the "see if unit is ready" command in the device menu. Sometimes the Exabyte goes crazy when it receives commands in the wrong moment, and sometimes it's still crazy when powered down and up after that. Similarly, you may use "Error/status info" to be sure that the tape is at beginning of medium, and rewind if it isn't.
When reset, any SCSI unit is in a "UNIT ATTENTION" status, and may refuse to accept commands until it exits from it. In theory this should be accomplished by sending it any SCSI command (e.g. a REQUEST SENSE, performed by "Error/status info") but the Exabyte seemed to pretend something more, e.g. a MODE SENSE, sometimes even two or three MODE SENSEs. The commands performed by suntar at "Open Device" always worked, but after an explicit "Reset" sometimes I had some difficulties to return to a normal status (NO SENSE, or NOT READY if the tape is missing). And, obviously, after an explicit reset the effect of the "do a MODE SELECT" option is lost: if your configuration requires "do a MODE SELECT"=yes, then after a Reset the tape will not work until the correct MODE SELECT is performed (either by closing/reopening or by the "MODE SELECT" command, which appears in the Device menu when verbosity is not 0 (see later).
Since the UNIX tar allows one to place more archives on a single tape, rewinding the tape in order to "go to sector 0" might really place the tape far from your data. Hence suntar avoids to automatically rewind the tape, and you must often use the explicit rewind command in the Device menu. "Skip filemark" commands are good for multiarchive tapes.
Unlike UNIX, the Macintosh was not thought to perform several operations in parallel. So, it does not support the way SCSI uses to allow the computer work while the device performs a slow operation, with one exception (rewind) for which the SCSI committee introduced an alternate method. Slow operations block the Mac, and for a Skip filemark this may last for several minutes, for a "Full erase" even for an hour. Suntar has a timeout, if after that time the operation has not finished it aborts the operation by resetting the SCSI bus. So, you must assign the timeout (rarely used options) before performing a full erase. There is one solution, the new SCSI manager supports parallel execution of SCSI commands, but exploiting it is not easy and certainly we can't try that until we'll have a machine which supports it.
Suntar was born for floppy disks and its default buffer size (9k) is good for floppy disks but is small for tapes. In order to increase it, simply allocate more memory to suntar. Or, if you don't like to have a different size each time you launch suntar, assign the "buffer size-encoded data" option to something bigger than 18.
If everything seems to fail, suntar offers some opportunities to experiment. When you do option-open device and assign a "verbosity level" greater than 0, suntar allows you to perform a MODE SELECT with any block size (as usual, 0 means "use variable sizes") and/or perform READ commands either fixed (place a "f" before the number) or variable ("v"). That's faster than modifying the blocking factor, closing the device and reopening. N.B. the option key may be pressed before clicking the mouse to select "Open device", or while releasing the button, or while double-clicking in the scrolling list.
A possible series of tests:
Use "MODE SELECT" to set block size to 0 ("MODE SENSE" tells you the current value, it's always wise to check that the command was correctly executed)
Do a "TEST SCSI read" of vnnnn bytes (where nnnn is "blocking factor" times 512): you're emulating "software fixed" mode
Do a "TEST SCSI read" of v1000000 bytes (or any number bigger than above): you're emulating "really variable" mode with a buffer size of 1000000
Now, perform a "mode select" of "blocking factor" times 512 bytes
Do a "TEST SCSI read" of fnnnn bytes (where nnnn is "blocking factor" times 512): you're emulating "firmware fixed" mode
If you want, you may also try other combinations. Anyway, at least one of these three reads should complete without error: on the Mac LC with the Exabyte all three operations succeeded. Be aware that sometimes the unit may go into an "error state" so that before doing an attempt it's better to verify that "Status/error info" tells that the unit is OK. Otherwise, reset it and wait until it's ready and not in error, then do the MODE SELECT and TEST SCSI read.
Remember that a fixed READ issued when the unit is in variable mode or vice-versa should yield a "ILLEGAL REQUEST" error code.
The coding of the "supported tape operation" is:
0 skip file forward
1 skip file backwards (both may be tested from the Device
menu, but beware: the SCSI-1 standard specifies a single error code
for these causes: command not supported, wrong parameters to the
command, the current status of the unit is not compatible with
executing the command (e.g. missing tape, or tape at end of medium):
so a failure does not mean that the command is not supported, unless
the unit supports the new SCSI-2 error codes (additional sense key).
If the "inquiry" data contains the list of supported commands, note that
0,1,2,3 are all implemented by command 11 of group 0, but it need not
implement all four operations
2 skip block forward ("fast forward" movement, may be tested with a
List of an archive containing files longer than the block size)
3 skip block backwards (may be tested by an "Append" command)
4 may use multiple fixed blocks reads and writes (see above)
5 do a MODE SENSE to get block size (see above)
7 write filemark (command 10 of group 0, may be tested from the Device menu)
9 short erase
10 long erase
11 end of medium
13 immediate rewind, that is letting the computer free while the tape unit performs the command
14 in "Drive list", suntar may try to detect the units which exploited the SCSI feature allowing one to connect more devices to a single controller and hence a single ID. Some old drives behave strangely when they're asked about this, so only a 14 in the "supported ops list" enables this.
some SCSI jargon:
MODE SENSE: ask informations about the unit and in particular the block size. But there are a lot of informations, suntar does not try to get all of them (try the freeware SCSI Spy on your hard disk, you'll be surprised…)
MODE SELECT: assign informations about the unit and in particular the block size
REQUEST SENSE: ask more informations about the last error occurred. Since the error code returned by the command which failed is very concise, in practice any program handling SCSI devices must perform a REQUEST SENSE every time a command fails.
bus reset: reset ALL the devices on the SCSI bus. Device manufacturers are usually free to choose what to do at reset, but at least they restore all temporary settings to their initial values. This may mean that the device and its device driver are now configured differently, and that device appears not to work until the driver is reloaded (i.e. the Mac is restarted): it's rare, but happened with old versions of the CD-ROM driver from Apple. When reset, a SCSI printer will abort any print job and maybe print its self-test page. So, a SCSI bus reset is sometimes not desirable, but a lot of units can oblige suntar to do that. Don't ask me why, but a lot of SCSI units when receiving an unknown command lock the bus, failing to release it. They don't say "pardon ? I did not understand", they do nothing, absolutely nothing, not even the simple action of releasing the bus. Now, the SCSI bus is occupied and nothing may be done on it, hence your hard disk(s) can't be accessed. So, suntar tries to reset the device which caused the problem. But the "reset device" command (well, technically it should be called "message": a message may interrupt the execution of a command) is often ignored too. Then, the only way to return to a good status is to reset the bus, hence ALL the SCSI devices connected to your Mac, with all its potential problems. Most hard disks may be reset without any problem, however.
Obviously, since suntar is freeware and we're distributing it only to help the people be happier with their computers, I'm waiting to hear news from you: if suntar works with a tape unit, tell me (by E-mail to the address in the readme file or in the about box of the application) which unit it is and how you've configured suntar, or which particular problems it creates and how you solved them. Users of future versions will find these informations in this file, near the informations for the Exabyte and Scorpion, and they won't be obliged to discover them by themselves. The informations will be much more useful if they're complete, i.e. you tried all the commands associated to a supported/unsupported bit and tried all the block strategies which are meaningful for that unit, but any information is useful. I'd like something like this (the informations from the "inquiry" are printed with verbosity 1):
Device type: Tape unit
Device type qualifier: 0
Removable: yes
ANSI version: 1
VendorID: EXABYTE
ProductID: EXB-8200
Revision: 425A
The list of supported commands is not available
MODE SENSE test
medium type 133
write protected: no
density code 0 blocks 2294048 block size 1024
READ BLOCK LIMITS test
reserved byte=0
minimum block size=1 maximum=245760
-------
unsupported ops: 2,3,11
supported: 0,1,4,7,9,10,13
block strategies and related options:
...... (place here all what you find useful, at least if the unit is "variable length", complete informations would include a description of the results of tests in all the three strategies, and with and without the options)
If, on the other hand, you have problems and can't solve them, well, our problem is that a SCSI operation yields a lot of different error codes, and in order to avoid to overwhelm you with a lot of meaningless numbers, what suntar usually prints is a "summary" error code, chosen among error codes created by Apple, which were not thought for tape units. "Error/status info" is more detailed, but often that's not enough. So, suntar 2 has a "debug mode" which prints all informations about what it's doing (or trying to do) and about error messages from the SCSI device: it's activated by option-open device and assigning a "verbosity level": you won't understand all those data (unless you are a SCSI expert) but maybe those informations will allow us to fix the problem. It's very convenient to use this with a "log file" opened from the "Special" menu.
